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BACKGROUND 

Field of the Invention 

The present invention relates to the transmission of electronic messages over computer 
networks, and more particularly, to a method and apparatus for managing and manipulating a 
plurality of electronic messages on the basis of pre-determined criteria. 

Background of the Invention 

During the past decade, electronic mail ("e-mail") has become an indispensable tool for 
facilitating business and personal communications. Through computer networking systems such 
as local-area networks ("LAN"), wide-area networks ("WAN"), and the world-wide web 
("WWW"), network users can send and receive notes, letters, documents and other messages to 
communicate with others who are in the same office or in remote locations across the world. 

E-mail application programs typically comprise client-server applications. That is, a mail 
server application ("mail server"), running on a server computer, provides centralized e-mail 
services for multiple users. The mail server application coordinates with other mail servers 
running on the network to send and receive e-mail messages composed by or addressed to local 
users. Any suitable protocol, for example, Simple Mail Transfer Protocol ("SMTP"), can be 
used to coordinate different mail server applications. Typically e-mail messages (inbound, 
outbound and in some cases, even "draft" e-mail messages) are stored by the mail server in 
"mailboxes" assigned to each user. These mailboxes typically comprise one or more files or 
directories (also known as folders) on a physical storage medium, e.g., a hard disk on the server 
computer. 
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Users typically use a client application running on a local computer to retrieve their e- 
mail messages from the mail server. As known in the art, client applications communicate with 
mail server applications using any suitable protocol (e.g., Post Office Protocol ("POP" or 
"POP3") or Internet Message Access Protocol ("IMAP" or "IMAP4")). Generally, e-mail 
5 messages are created, viewed and/or managed using the client application. That is, the client 
application must be opened (i.e., executed) on the client computer to access the e-mail messages. 

After downloading a user's e-mail messages from the user's mail server, the mail server 
application may be instructed to automatically delete the message from the user's mailbox on 
the server. Alternatively, a copy of the message may be retained on the server for later access. 
^ In either case, after retrieving the e-mail messages, the user may read the messages on the local 

computer even if the server computer is no longer accessible, 
p E-mail service providers typically limit the amount of physical storage space available for 

]jf each customer. Such limits are typically used to ensure adequate storage space is available for 

other users, and in some cases are necessary to ensure adequate operational efficiency of the mail 
jif server. Implementation of such limits typically include restrictions on the aggregate file size for 
Q all e-mail messages in a particular user's mailbox. In some cases, e-mail service providers limit 
the total number of e-mail messages stored by a user on the server. Because of such limits, e- 
mail users face the recurring problem of meeting or exceeding the storage space limits imposed 
by their e-mail service providers. E-mail service provider policies may vary with respect to the 
20 consequences of exceeding the allotted storage space. For example, the service provider may 
prevent additional e-mail from being sent or received by the user until the amount of storage 
space is reduced, or the service provider may assess additional charges on the user for each 
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message or storage space unit over the limit. Regardless of the policy employed, the 
inconvenience or additional costs imposed on a user can be severe. 

To overcome these limits, users typically delete e-mail messages from the server after 
downloading them to the local computer. However, this approach results in other problems or 
inconveniences for many users. For example, if a user accidentally deletes one or more 
messages from the local computer, and the local computer system has not been backed up, 
important e-mail messages may be permanently lost. Additionally, some e-mail users do not 
have a dedicated local computer for downloading and saving e-mail messages. Such users may 
access their e-mail from shared access computers or from public access terminals. For these 
users, the mail server may be the only permanent storage location available. Finally, if e-mail 
messages are maintained on the mail server, the messages are available to the user from any 
client application running on the network. Accordingly, e-mail users need the capability to store 
and manage e-mail messages on the mail server not withstanding the limits on mail server 
storage facilities. 

Downloading and storing e-mail messages on a local computer may solve the problems 
described above as they relate to the e-mail server application and host computer. However, 
many of the same problems could arise with respect to the user's client application and local 
computer system. For example, the local computer may have only a limited amount of storage 
space, or the client application may experience performance problems if the user's local mailbox 
is too large. Generally, the user's mailbox size will be proportional to the number of e-mail 
messages in the mailbox and the aggregate message size of the items within. Accordingly, a 
need exists for methods and systems for managing and compacting e-mail messages stored on a 
local computer system. 
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To compound the problem, e-mail messages typically comprise one or more attached 
files, greatly increasing the size of the e-mail messages. Users typically export (i.e., save) e-mail 
messages and or attachments to a location external to the client application and files. Once an e- 
mail message or attachment has been exported, it may be viewed or managed using other suitable 
5 application programs. The problem with exporting e-mail messages and attachments is that users 
lose the inherent ability of the e-mail client application to manage e-mail messages in the form 
they were received. For example, e-mail messages associated with a recurring subject (also 
known as "threads") may not be readily viewed external to the e-mail client. Similarly, if an 
attachment is separated from the e-mail message, it becomes more difficult to locate the 
|U attachment and to determine when it was sent or received and who the sender or recipient was 
*u for the document. Accordingly, e-mail users need the capability to store and manage e-mail 
Q messages on local computers without losing the beneficial features of the mail client application. 
|« Current e-mail server and client applications do not provide efficient tools for users to 

: ; a effectively manage the size or number of e-mail messages. E-mail client and server applications 
j(5 typically allow users to sort e-mail messages by date, subject, or the sender or receiver's name. 
□ However, such applications do not allow the user to sort or screen e-mail messages by size, and 
they do not provide the capability to compact e-mail messages or attachments for future access 
within the e-mail application. A need therefore exists for the capability for e-mail users to 
manage the size of e-mail messages whether stored on a mail server or on a client computer 
20 system. 

SUMMARY OF THE INVENTION 

The present invention is a method and apparatus for managing and compacting, i.e., 
reducing the size of, electronic mail messages stored on a server computer, on a client computer 
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or on both a server and a client computer. The method and apparatus can be implemented on a 
server-wide basis wherein every e-mail message on the server is checked against a 
predetermined criteria to determine if compacting is required. In this embodiment, every e-mail 
message, including inbound and outbound messages to or from every user on the mail server 
5 system, is screened for such compacting. Alternatively, individual e-mail users may implement 
customized compacting procedures on the mail server or on their respective client computer 
systems. 

Compacting procedures for e-mail messages include compressing the e-mail message, 
compressing any e-mail attachments, compressing both the e-mail message and any e-mail 
HO attachments, or detaching e-mail attachments from the message. If the e-mail attachments are 
; y detached from an e-mail message, the detached files may be stored in a location external to the e- 
O mail application and an index is inserted in the message for future reference, 
j-ff The predetermined criteria used to screen e-mail messages may comprise a threshold 

j\ limit on the total size of an individual e-mail message, without or with attachments, the total size 
\Xs of all attachments to a single e-mail, or the individual size of any one attachment in an e-mail 
q message. Alternatively, the criteria could be based on whether or not an e-mail message 

comprises any attachments at all, the number of attachments to an individual e-mail message, the 
expected compression ratio for the e-mail message or attachments, or the file-type of any 
attachments. In an alternative embodiment, the predetermined criteria comprises a message 
20 subject, a sender's name, or some other identifiable message attribute. 

It is an object of the present invention to provide e-mail users with a system and method 
for managing and compacting their e-mail messages to conserve storage space on an e-mail host 
or local computer system. 
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It is another object of the present invention to provide e-mail system administrators with 
tools to more effectively manage e-mail services. 

It is another object of the present invention to automate screening of e-mail messages to 
identify e-mail messages requiring compacting. 

It is another object of the present invention to automate compacting procedures for e-mail 
server and/or e-mail client systems. 

It is another object of the present invention manage e-mail attachments external to an e- 
mail server or client application by separating the attachments from the messages and inserting 
links indicating the addresses of any attachments so separated. 

These and other objects of the present invention are described in greater detail in the 
detailed description of the invention, the appended drawings and the attached claims. 
DESCRIPTION OF THE DRAWINGS 

Figures 1 A - 1C are schematic diagrams showing the message flow in an e-mail system 
according to an embodiment of the present invention. 

Figure 2 is a message flow diagram showing the overall architecture and options used in 
an embodiment of the present invention. 

Figure 3 is a flow diagram showing some of the steps performed in a preferred 
embodiment of the present invention. 
DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 A shows a typical network architecture used in an embodiment of the present 
invention. Figure 1 A shows how three users (Users A - C) send and receive e-mail via 
associated client computers or terminal interfaces and e-mail server systems. As shown in 
Figure 1A, host 10 is an e-mail server system comprising one or more electronic mailboxes 
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assigned to one or more users. In Figure 1 A host 10 has an e-mail server application providing 
e-mail service for users A and B. User A has a client application, running on computer 12, for 
sending and receiving e-mail via the e-mail server application on host 10. As shown in Figure 
1A, computer 12 communicates with host 10 via network 14. User B uses terminal 16, directly 
connected to host 10, to send and receive e-mail messages via the server application on host 10. 
User B may use a client application running on server 10, or if User B has sufficient skill and 
system privileges, User B could interface directly with the server application on host 10. The 
third user shown in Figure 1 A, User C, has computer 18 and subscribes to e-mail services 
provided through host 20. 

In a first embodiment of the present invention, an e-mail system administrator may 
implement server- wide criteria for managing and compacting e-mail messages processed by the 
server. In this embodiment, all e-mail messages processed by a server, e.g., host 10, are screened 
against some predetermined criteria. The administrator may also define exceptions to the 
screening criteria and compacting procedures to handle special cases. For example, the 
administrator may choose to exempt those users willing to pay for unlimited storage space. 

In this embodiment, the system administrator for host 10 may implement a screening 
criteria to identify all e-mail messages greater than 500K bytes. In this example, assume that the 
administrator's compacting procedures directs the system to process (i.e., mail out) any messages 
exceeding the size limit, but compacts such e-mail messages prior to storing them in a user's 
mailbox. Accordingly, outbound messages (i.e., from a user served by host 10) are transmitted 
before any automatic compacting procedures are performed. However, all messages, including 
both inbound and outbound messages, are compacted prior to their being stored on host 10. For 
example, if user A sends uncompacted e-mail message 1 to user C, the message first travels from 



computer 12 to host 10. When host 10 receives uncompacted message 1, the e-mail server 
application tests the message against the screen criteria. In this example, uncompacted e-mail 
message 1 is 800K bytes, and so the message will be processed according to the system 
administrator's compacting procedures. 

The server application on host 1 0 receives uncompacted e-mail message 1 and sends it on 
to host 20 as uncompacted e-mail message 1, as shown in Figure 1A. The server application 
then compacts e-mail message 1 into compacted e-mail message 1' which is stored in user A's 
mailbox (Mailbox A) 101 on host 10. Conversely, when User A wishes to read compacted e- 
mail message 1 ' the server application temporarily uncompacts the message and sends the 
uncompacted message to User A on computer 12 through network 14. 

Continuing in this example, if User C sends either User A or User B an e-mail message 
larger than 500K bytes, the message will be compacted automatically before being stored in the 
users' respective mailboxes, as shown in Figure IB. In Figure IB, User C sends uncompacted 
message 2 to Users A and B. Uncompacted message 2 flows through host 20 to host 10. The 
server application on host 10 checks uncompacted message 2 to determine if it requires 
compaction. If so, compacted message 2' is stored in User A and User C's mailboxes 101 and 
102, respectively. In an alternative embodiment, the server application may wait until the user 
has read his or her inbound e-mail messages and compact them only if the user decides to save 
the message for later use. 

In another example, shown in Figure 1C, the system administrator of host 10 may 
mandate that all e-mail messages exceeding the 500K byte threshold are to be compacted prior to 
sending them out to other hosts. In this case, when User B sends 1 .2M byte uncompacted e-mail 
message 2 to User C, the server application applies the screening criteria as described above. 
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Since the message meets the screening criteria, the server application compacts the message prior 
to sending it on to User C (via host 20). As shown in Figure 1 C, uncompacted e-mail message 3 
becomes compacted e-mail message 3' which is then stored in Mailbox B 102 and sent to host 20 
for delivery to User C. 

5 In an alternative embodiment, the server application may be configured to provide 

individual users with the capability to define their own screening criteria and compacting 
procedures to be followed on the server. In this embodiment, users may tailor the system 
according to their own specific requirements for managing and compacting their e-mail on the 
host system. Such customized settings may even be implemented as a supplement to the server- 
Ejp wide processing discussed above. User settings may be transmitted to the server application in 
■y any suitable manner. For example, the user may send an e-mail directly to the system or to the 
O system administrator for processing. Alternatively, a graphical user interface ("GUI") may be 
•*f provided for managing the user's account on the host computer. Such GUI interface could be 
|\_ accessible via the world-wide web or other network interface. 

\\§ In another alternative embodiment, a user can manage and compact e-mail messages 

□ stored on the user's local computer by implementing screening criteria and processing 

procedures to be followed by the e-mail client application. As described above, users often 
download e-mail from a server to a local computer. Limitations in available storage space on the 
user's local computer and performance problems can result from storing numerous large e-mail 
20 messages or message attachments for management within the e-mail client application. The e- 
mail client application may be modified to provide automated message processing according to 
the present invention. 



9 



* # 

Compacting procedures for e-mail messages may be implemented using conventional 
methods such as compressing the e-mail message, e-mail attachments, or both the message and 
attachments. Compacting procedures could also be implemented by detaching e-mail 
attachments from the message, and replacing the attachment with an index for retrieving the 
attachment at a later date. The attachment may be exported or saved on a storage device on the 
local computer or could be saved on a different computer and storage device reachable via a 
network including, e.g., the world-wide web. In a preferred embodiment, the index comprises a 
universal resource locator ("URL") pointing to the address of the attachments. The e-mail client 
application may be configured to automatically save the attachment in either uncompressed or 
compressed format. Similarly, the e-mail client application may be configured to automatically 
decompress attachments when the user selects the index (or URL link) for viewing the 
attachment. 

The message flow diagram in Figure 2 illustrates the steps used in an embodiment of the 
present invention. Although Figure 2 shows multiple branches in the process, it is to be 
understood that a user or system administrator may implement more than one branch 
concurrently. At process control point 200 the overall system architecture for implementing the 
present invention is selected. As shown in Figure 2, the e-mail system administrator may 
implement server-wide screening 202, or the user may implement screening procedures on the 
server (step 204) or screening procedures on the client (step 206). In step 210, the screening 
criteria is selected. As noted in Figure 2, the criteria could also be used to determine how e-mail 
is sorted for viewing by the users. As shown in Figure 2, the screening/sorting criteria may 
comprise message weight 212, attachment weight 214, attachment type 216 or compression ratio 
218. Message weight 2 1 2 and attachment weight 2 1 4 use the size of the message or message 
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attachments to determine if the e-mail should be processed according to the present invention. 
Similarly, attachment type 216 examines the file format of the attachments to make the 
determination. For example, if the attachment is a "zipped file," i.e., it is already compressed, 
the message may not require or be capable of further compacting procedures. Compression ratio 
218 is used if the criteria seeks to measure the expected benefit of processing e-mail messages 
according to the present invention. 

If a message meets the screening criteria, then the process moves on to compacting 
procedures 220. As shown in Figure 2, the e-mail message may be compressed in step 222, the 
attachment may be compressed in step 224, or the attachment may be removed and indexed in 
steps 226. Any combination of these compacting procedures may be implemented as described 
above. 

In the example described in Figure 3, the system administrator has configured the server 
application to screen messages having an overall size greater than one megabyte ("1.0M") or 
those having attachments greater than 800K in size. As shown in Figure 3, the process starts in 
step 300 when an email message is received by the server. In step 302 the server checks the 
incoming message to determine the next step. If the message is not greater than 1 .0M, the 
process moves on to step 304 where the message is checked for attachments. If the message is 
greater than 1.0M, the process moves on to step 306 where the compacting procedures are 
followed. 

If in step 304 the message has no attachments, the process is complete and the email 
server application continues normal message processing. For example, if the incoming message 
was a message addressed to a user served by that email server, the message is stored in the user's 
mailbox. On the other hand, if the message is addressed to external users (i.e., users served by 
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different servers) it is sent on without any further intervention by the present invention in step 
305. If in step 304, the message has attachments, the process moves on to step 308 where the 
individual attachments size is checked. As shown in Figure 3, if any attachments are greater than 
800K, the process moves on to step 310. Otherwise, if none of the attachments satisfy the 
criteria, the process ends with step 305, as described above. In step 310, for attachments 
exceeding the 800K screening criteria, the attachment type is checked. If in step 3 10 an 
attachment is "zipped" the attachment is already compressed. In this situation, there is no need 
for further compacting of the message and the process ends with step 305. Note that if there are 
multiple attachments exceeding the size criteria, the server application will perform step 310 for 
each such attachment before moving on to step 305. In the present example, the attachments are 
only checked for those already zipped when they are received. Other attachment types could be 
defined for specific compacting procedures. In this case, in step 305 would include checking for 
each defined attachment type to determine the next step. In step 305 of the present example, if 
an attachment is not zipped, the process moves on to step 306 where compacting procedures are 
applied. 

In another embodiment of the present invention, e-mail messages are checked or screened 
against the predetermined criteria on a periodic basis rather than every time a message is 
received at the server. This embodiment may be preferable if there are performance concerns for 
the e-mail server application. The system administrator could setup a nightly routine for 
checking all e-mail stored in users' mailboxes for those messages satisfying the criteria. Any 
messages meeting the criteria are then processed according to the compacting procedures as 
described above. 
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The foregoing disclosure of embodiments of the present invention has been presented for 
purposes of illustration and description. It is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. Many variations and modifications of the embodiments 
described herein will be obvious to one of ordinary skill in the art in light of the above 
disclosure. The scope of the invention is to be defined only by the claims appended hereto, and 
by their equivalents. 
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